In an Information-Centric Network (ICN) such as a Content-Centric Network (CCN) or a Named Data Network (NDN), (collectively referred to herein as ICNs), a content router is responsible for routing user requests and content to proper recipients. In an ICN, a domain-wide unique name is assigned to each entity that is part of a content delivery framework. The entities may comprise data content, such as video clips or web pages, and/or infrastructure elements, such as routers, switches, or servers. The content router uses name prefixes, which can be full content names or proper prefixes of content names instead of network addresses, to route content packets within the content network. In ICNs, content delivery including publishing, requesting, managing (e.g., modification, deletion, etc.) may be based on content name and not content location. One aspect of ICNs that may be different from traditional Internet Protocol (IP) networks is the ability of ICNs to interconnect multiple geographical points and cache content temporarily or store content on a more persistent basis. This may allow content to be served from the network instead of an original server, and thus may substantially improve user experience. The caching/storing may be used for real time data that is fetched by the user or for persistent data that belongs to the user or to a content provider, e.g., a third party provider.
Consider the problem of service discovery in an ICN. It may be desirable to have a name-based service discovery solution, other than an address-based service discovery built on IP as described in Zero Configuration Networking (Zeroconf) a copy of which may be found at www.zeroconf.org and which is incorporated herein by reference as if reproduced in its entirety. An Exclusion Filter (EF) mechanism has been proposed for this purpose and implemented in CCNx, where discovered service names are included in an exclusion filter of repeated discovery interest messages with the same name prefix, and returned data messages with the service name in this filter will be excluded, so at most a new service name will be discovered in each round if it exists. (More information regarding the EF mechanism may be found at conferences.sigcomm.org/sigcomm/2011/papers/icn/p68.pdf which is incorporated herein by reference as if reproduced in its entirety.) However, this EF mechanism may not be efficient since a single discovery session needs multiple rounds of interest-data message exchanges depending on the number of service names to be excluded, and it may be difficult for an end user to decide when the discovery protocol should be ended due to the unknown number of service names to be discovered.